feat(sdk)!: pure DPNS and DashPay document builders shared with embedders - #4632

Issue being fixed or feature implemented

Carries forward the pure-builder half of #4619, without that PR's request-driven FromProof<GetDocumentsRequest> verifier, which the SDK-first C++ embedding (next PR in this series) no longer needs: the SDK retains the rich query it built and verifies against it, so no wire request is reconstructed from bytes.

dash-sdk's register_dpns_name and create_contact_request assemble DPNS and DashPay documents inline. An embedder that signs with a wallet-held key (Dash Core's platform GUI) needs the same assembly as a pure function over caller-supplied entropy, salt and ciphertexts, and must not reimplement it in C++.

What was done?

Pure document builders, in dash-platform-queries:

• dpns_usernames::{build_dpns_preorder_document, build_dpns_domain_document, salted_domain_hash} and dashpay::build_contact_request_document, the assembly halves of dash-sdk's register_dpns_name / create_contact_request as pure functions. dash-sdk's networked flows now call them.
• They reuse what exists rather than re-deriving it: normalization is dpp's consensus convert_to_homograph_safe_chars (the crate's ASCII-only copy is replaced by a re-export); the preorder commitment uses dpp::util::hash::hash_double; property names come from the dpns-contract / dashpay-contract constants; the DashPay byte bounds are read from the contract schema's DocumentPropertyType sizes instead of being hard-coded to the same numbers.

This is a move, not a rewrite. The documents the builders produce are byte for byte what the inline SDK code produced. The normalization swap is the only substitution, and the two implementations agree on every label the contract's ASCII-only pattern admits — they differ only on non-ASCII input, which consensus rejects anyway. The re-export additionally makes the crate agree with the DPNS data trigger.

Deliberately not in this PR

Two behaviour changes were dropped to keep this reviewable as a pure extraction. Both are worth doing on their own:

• No new label validation. An earlier revision rejected labels via is_valid_username before the preorder was paid for. That helper is stricter than the DPNS contract — it also refuses consecutive hyphens, which the contract's ^[a-zA-Z0-9][a-zA-Z0-9-]{0,61}[a-zA-Z0-9]$ pattern admits — so it would have refused names Platform accepts, on paths (wasm-sdk, platform-wallet) that previously had no local check at all. Failing early on a bad label is a real improvement, but it should check the contract's actual pattern, and it belongs in its own PR alongside a fix to is_valid_username's docstring, which currently claims the pattern forbids consecutive hyphens.
• No entropy/document-id check in dpp. dash-sdk keeps its existing private ensure_entropy_matches_document_id. Hoisting it into DocumentCreateTransitionV0::from_document so every caller (SDK, wasm, FFI, embedders) inherits it is a good change — it cannot change any outcome, since it only refuses transitions Drive would reject after the nonce bump — but it adds an error path to a shared crate and is separable from this move.

packages/rs-dpp and put_document.rs are therefore byte-identical to v4.2-dev in this PR.

The autoAcceptProof bound is still checked in create_contact_request before the recipient lookup. The shared builder re-checks it against the schema, but that field is raw caller input and the lookup is a network round trip, so the early rejection is preserved. The two checks on the SDK's own encryption output are dropped as unreachable code — the pre-existing COMPACT_XPUB_LEN guard forces the encrypted xpub to 96 bytes, and fit_account_label bounds the encrypted label to 48-80 — and the builder covers both for embedders doing their own encryption.

How Has This Been Tested?

• dash-platform-queries: 60 lib tests pass, including builder tests against the real DPNS/DashPay system contracts (preorder commitment matches the domain document's salt+label, id derivation, schema byte-bound enforcement).
• dash-sdk --lib: 187 pass. cargo check clean for platform-wallet, rs-sdk-ffi, strategy-tests, rs-scripts. cargo fmt --check clean.
• Byte-parity check: a scratch test reproduced the pre-PR inline assembly verbatim (including the old ASCII normalizer and the old sha256d helper) and asserted document equality against the new builders, across several DPNS labels — including alice--bob, -bad and ab, which the dropped gate used to reject — and a contact request with every optional field populated. All equal. Not committed; it exists only to prove the extraction.
• Not done here: a live-network run of register_dpns_name / send_contact_request. The on-wire behaviour is byte-identical by construction and the unit tests pin the property maps.

Breaking Changes

API shape on unreleased v4.2-dev (not on crates.io): dash_sdk::platform::dashpay::ContactRequestResult now carries the assembled document plus entropy instead of id / owner_id / properties. No consumer outside rs-sdk uses it. No behavioural breaking changes.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

Summary by CodeRabbit

• New Features

  • Added helpers for creating DashPay contact request documents with encrypted-field validation.
  • Added helpers for creating DPNS preorder and domain documents, including label normalization and salted hash generation.
  • Exposed document-building utilities through the DashPay and DPNS SDK modules.

• Improvements

  • Contact request and DPNS registration workflows now share document construction and validation.
  • Improved handling of data contract validation errors.

• Tests

  • Expanded automated coverage for contact requests and DPNS document creation.